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ABSTRACT 


The Ares I and Ares V Vehicles will utilize the J-2X rocket engine developed for NASA by the Pratt & Whitney 
Rocketdyne Company (PWR) as the upper stage engine (USE). The J-2X is an improved higher power version of 
the original J-2 engine used for Apollo. System Engineering (SE) facilitates direct and open discussions of issues 
and problems. This simple idea is often overlooked in large, complex engineering development programs. Definition 
and distribution of requirements from the engine level to the component level is controlled by Allocation Reports 
which breaks down numerical design objectives (weight, reliability, etc.) into quanta goals for each component area. 
Linked databases of design and verification requirements help eliminate redundancy and potential mistakes inherent 
in separated systems. Another tool, the Architecture Design Description (ADD), is used to control J-2X system 
architecture and effectively communicate configuration changes to those involved in the design process. But the 
proof of an effective process is in successful program accomplishment. SE is the methodology being used to meet 
the challenge of completing J-2X engine certification 2 years ahead of any engine program ever developed at PWR. 
This paper describes the simple, better SE tools and techniques used to achieve this success. 


CONSTELLATION PROGRAM/ ARES PROJECTS 

As a result of President Bush’s Vision for Space 
Exploration announced in January 2004 and 
subsequently made national policy by Congress, 
NASA embarked on the development of a new 
launch vehicle system to fulfill the U. S. national 
goals of replacing the Space Shuttle fleet and 
returning to the moon. These goals were shaped by 
the decision to retire the shuttle fleet by 2010, 
budgetary constraints, and the requirement to create a 
new fleet that was safer, more reliable, operationally 
more efficient than the shuttle fleet, and capable of 
supporting long range exploration goals. The present 
architecture for the Constellation Program is the 
result of extensive trades during the Exploration 
Systems Architecture Study and subsequent 
refinement by the Ares Project Office at Marshall 
Space Flight Center. 

Figure 1 shows The Ares V Cargo Launch Vehicle 
(left) and Ares I Crew Launch Vehicle (CLV) in 
parallel flight (not a mission configuration) (NASA 
artist’s concept). These will be the first new human- 
rated launch vehicles developed by NASA in more 
than three decades. Ares I will demonstrate its initial 
operating capability of flying up to six astronauts to 
the International Space Station (ISS) no later than 


2015. Ares V is scheduled to be operational in the 2020 
timeframe to support the lunar mission. 

Figure 2 shows the location and use of the J-2X engine 
aboard the Ares-I CLV and Ares-V CaLV vehicles 
compared to the Saturn V with its multiple J-2 Engines. 



Fig. 1 : Ares I, Ares V Vehicles in Flight 
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Ares -I CLV Ares-V CaLV Saturn V 


Fig. 2: J-2X and J-2 Aboard Vehicles 

The reference lunar mission is still under 
development. There are scenarios where Ares I 
launches first and others where Ares V launches first. 
Regardless of the particular scenario, however, they 
all include the on-orbit docking of the Orion Crew 
Exploration Vehicle (CEV) carried by Ares I and the 
Earth Departure Stage carried by Ares V prior to 
heading to the moon. 

The Ares V first stage propulsion system consists of a 
Core Stage powered by six commercial liquid 
hydrogen/liquid oxygen (LH2/LOX) RS-68 engines, 
flanked by two five-segment solid rocket boosters 
(SRBs). Atop the Core Stage is the Earth Departure 
Stage (EDS), powered by a single J-2X Upper Stage 
Engine and a payload shroud enclosing the lunar 
lander. 

The Ares I first stage consists of a single five- 
segment SRB. Once that stage is expended during 
launch, the Upper Stage, powered, by a single J-2X, 
will ignite to take the Orion into orbit. The ED S/lunar 
lander will go into a stable checkout orbit. After 
Orion docks with the EDS/lander, the J-2X will ignite 
a second time to begin trans-lunar injection (TLI). 
The EDS would be discarded at the end of the TLI 
bum. The Orion and Lunar Lander perform the 
remainder of the mission, with Orion remaining in 
lunar orbit autonomously while the crew descends to 
the Moon in the lander. At the end of the surface stay, 
the crew returns to Orion in the lander ascent stage, 
which is then discarded. The crew returns to Earth in 
the Orion Crew Module for reentry and landing. 

COMMUNICATION INFRASTRUCTURE 

Ockham’s razor is a principle attributed to the 14th- 
century English logician and Franciscan friar William 


of Ockham. The principle states that the explanation of 
any phenomenon should make as few assumptions as 
possible, eliminating those that make no difference in the 
observable predictions of the explanatory hypothesis or 
theory. This is often paraphrased as "All other things 
being equal, the simplest solution is the best." It is in this 
sense that Ockham’s razor is usually understood and 
applied to SE principles. 

In our high technology business world, such simple 
advice is often discarded in favor of highly detailed 
models and sophisticated electronic communication 
systems. To be sure, such systems are necessary to 
achieve accurate solutions to complex problems, to 
overcome the problems of physical distance and different 
time zones among working groups and to provide 
documentation securely on a very rapid schedule. 
However, J-2X personnel have also found the wisdom of 
William of Ockham’s words by continuing to use the 
simplest of communication devices: talking to each 
other - to help assure complete understanding of program 
direction and issues. The program has established a 
culture of completely open communication with NASA. 
The NASA and PWR SE Teams embraced and 
encouraged this modus operandi with the usual major 
design reviews but supplemented by Technical 
interchange meetings (TIMs), teleconference tie-ins to 
Working Group meetings (Table 1 below), and other 
teleconference meetings with NASA on specific subjects. 

J-2X SYSTEMS ENGINEERING 

Regarding the J-2X NASA/Pratt & Whitney Rocketdyne 
(PWR) implementation of SE principles, it has been 
humorously said that the NASA side does not do 
anything. While that is a bit harsh, it is recognized that the 
Ares Project integrates the vehicle and PWR builds the 
J-2X engine. Further, the NASA J-2X Systems 
Engineering and Integration (SE&I) office is not 
responsible for coordinating or overseeing any hardware 
deliveries. It is not directly responsible for even the 
official documentation against which the J-2X will be 
built, verified, and with which the engine will be flown. 
On the other hand, without the NASA J-2X SE&I office 
not much would happen. So the statement that the NASA- 
side J-2X SE&I office does not do anything is really 
nothing more than an admonishment to keep things as 
SIMPLE as possible. 

Within the realm of SE, separate from the activities of 
vehicle and stage integration, the NASA J-2X SE&I 
office coordinates "the in’s and the out’s," meaning that it 
acts as the conduit for critical information back and forth 
between the Ares Project and the PWR J-2X development 
effort. This communication takes many forms, but the 
following disciplines form the core: Requirements 
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Management, Risk Management, and Technical 
Review Management. 

Requirements management in this context involves 
the structured communication of contract 
requirements and program needs to the point of 
application, the developer of the hardware. The 
NASA J-2X SE&I office handles this at the system 
level through the maintenance of the J-2X Element 
Requirements Document (J-2X ERD). This 
requirements document acts as the intermediate point 
between the needs of the vehicle, both the Ares I and 
the Ares V as expressed in two systems requirements 
documents, and the engine system specification 
developed, delivered, and maintained by PWR and to 
which the J-2X is built. The J-2X ERD expresses the 
performance, functional, and physical characteristics 
that the J-2X shall have to meet Constellation 
objectives. It also provides ‘how-to’ direction in the 
form of design and construction standards from 
NASA and other organizations. Figure 3 shows the 
flow down of requirements from the highest levels 
through the J-2X ERD and how this feeds the engine 
system specification developed by PWR. 

At the next organizational level down, in order to 
facilitate the critical insight role that NASA plays in 
the J-2X development effort, the NASA J-2X SE&I 
office develops and maintains a J-2X Component 
Requirements Document (J-2X CRD). This is not a 
collection of all the requirements to which the 
various engine subsystems and components must be 
built. Also, it is not the function of the NASA J-2X 
SE&I office to specifically define how the 
constituents of the engine are built to meet the 
mandated system-level requirements. Rather, the 
J-2X CRD contains direction for the key subsystem 
and component derived requirements as expressed by 



Fig. 3. J-2X Technical Requirements Flowdown 


the combined NASA/PWR technical community. These 
requirements are those for which formal tracking and 
verification are necessary to accomplish effective insight 
to the development of the engine. In other words, the J-2X 
CRD is a communication tool between technical 
disciplines and designers that is enabled by the NASA J- 
2X SE&I office. 

Another key communication tool takes the form of 
tracking programmatic and technical risks. PWR is 
ultimately responsible for risk management of the J-2X 
development effort at the detailed part level, but NASA 
acts as the programmatic interface between those risks 
managed and mitigated internally and those expressed to 
the Ares Project and the Constellation Program. Whereas 
requirements flow downwards, risks flow upwards. It is 
the function of program management to determine how 
far risks are raised organizationally, how resources are 
allocated to mitigate the risks, and at what level decisions 
must be made along these lines to achieve risk resolution. 
The NASA J-2X SE&I office provides the linkage 
between the PWR risk database and communication 
through the NASA risk database so as to make this 
management possible. 

Nothing so far has been said about the classic structure of 
SE, the V consisting of requirements allocation on one 
side and development, verification, and validation on the 
other. Yet, this is how the J-2X development effort is 
being conducted. The NASA J-2X SE&I office facilitates 
this structure not only through the communication tools 
discussed above, but also through a series of milestone 
reviews consistent with NASA agency policy. The NASA 
J-2X SE&I office translates NASA policy along these 
lines into a series of plans for milestone reviews. Thus far, 
the J-2X development effort has progressed through the 
System Requirements Review (SRR), the System 
Definition Review (SDR), the Preliminary Design Review 
(PDR), and the Critical Design Review (CDR). Yet to be 
accomplished, but with identified target dates on the 
calendar, are the Production Readiness Review (PRR) 
and the Design Certification Review (DCR). For each of 
these reviews, a plan is generated describing the review 
process, the review goals, and the criteria by which the 
development activity will be judged a success or against 
which greater emphasis must be applied to help assure 
success in the future. 

So while it is true that the NASA J-2X SE&I office on 
the NASA side does not do anything in terms of 
delivering hardware, it plays an essential programmatic 
roll. Through the development and maintenance of a 
purposeful number of key documents; the J-2X ERD, the 
J-2X CRDs, and the series of milestone review plans, the 
NASA J-2X SE&I office provides the driving force and 
structure for the development effort. Through the 
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communication and coordination of key risks 
between the PWR and NASA databases, the 
NASA J-2X SE&I office facilitates ongoing program 
management success. Figure 4 shows the functional 
organization of the PWR SE team and indicates the 
penetration points for those key elements of the 
NASA SE effort which drive the SE effort. 
Abbreviations on Figure 4 include Reliability, 
Maintainability, System Safety (RMSS), System 
Engineering and Integration Team (SEIT), and Non- 
Destructive Test (NDT). 

TOOLS AND TECHNIQUES FOR J-2X SE 
REGULAR TELECONS/PROGRAM LEVEL 
MEETINGS 

Each of the PWR Integrated Products Teams (IPT) of 
the J-2X program holds regular (weekly, etc.) 
teleconferences with their counterpart organizations 
in NASA. The purpose of these teleconferences is to 
exchange information about the course of events 
between the last teleconference and the current one. 
The program has never found a good reason not to 
have a teleconference. They are occasionally 
rescheduled because of the unavailability of key 
personnel but there is always a good reason to 
communicate regularly. The typical subject matter 
includes requirements changes, verification planning, 
vehicle interface issue discussions, upcoming events, 


and long range commitments which require regular 
attention to maintain schedule. 

Table 1 identifies just 3 of more than 15 regular meetings 
held to maintain a high quality level of communication 
between PWR and NASA. The table identifies the 
technical coordination working meetings, their purpose, 
frequency, organizer, and attendees. PWR IPT leaders are 
responsible for organizing intra-IPT meetings at their 
discretion. Abbreviations on Table 1 include System 
Engineering Working Group (SEWG), Engine 
Development Working Group (EDWG) and Engine 
Integration Working Group (EIWG), Program Manager, 
Deputy Program Manager (PM/DPM), Engineering 
Review Board (ERB), Integrated Product Team (IPT), 
and Concept of Operations (ConOps). 

It’s as SIMPLE as that - talk to each other regularly. 

NEXPRISE (INFORMATION PARAPHRASED FROM 
NEXPRISE SECURITY WHITEPAPER, JUNE 2007, 
AVAILABLE ON NEXPRISE WEB) 

The J-2X program is using NexPriseTM as a secure inter- 
site communication tool. The NexPriseTM Web Space 
platform is a 100% Web-based solution designed to 
facilitate improved communication, change management 
and project execution with remote and project execution 
with remote partners, suppliers, customers and 
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Table 1: Technical Coordination Working Meetings 


Meeting Lead Attendees 

Title Team Attendees 


Objectives/Purpose/Charter 


Decision Making 
Authority 


Frequency 


SEWG 


EDWG 


EIWG 


Office PWRSEIT&IPT 

of Chief Leads & PM/DPM; 

Engr NASA Chief Engr, 

SEIT Lead, & Prog 
Office; Architects; 
Integrators & Specialty 
Personnel as required 


SEIT Lead dev person or 
designated dev rep 
from each IPT 


Eng Lead designer or 

Integ designated design rep 

from each design IPT 


Operated as an ERB. 

Coordination, integration, and 
review of significant technical and 
design efforts, including: 

- engine & sub-system 
architecture/design configuration 
definition & management; 

- trades & specific issue 
resolutions & impacts; 

- engine-wide analyses, plans, 
allocations, & assessments; 

- general engine requirements, 
policies, and guidance. 

EDWG is held in order to discuss 
system functional integration, trade 
studies, and architecture 
development issues between 
component teams that need to be 
worked in a forum less formal than 
SEWG but more formal than email 
or one-on-one discussions. Also 
status/review of ConOps, test 
planning, facility planning, & assy 
planning. (In the future, become a 
forum for test & flight ops 
integration.) 

Coordination forum for physical 
layout and integration of the 
engine system. Also to work 
physical interface trades with 
vehicle. 


A decision making Weekly 
body for technical 
items & issues 


A working meeting to Weekly 
develop 

recommendations for 
SEWG. 


A working meeting to Weekly 
develop 

recommendations for 
SEWG. 


employees. Designed for security, rigid 
implementation, and ease of use, the NexPriseTM 
solution offers a SIMPLE , proven, B2B extranet 
platform specifically designed to facilitate secure 
collaboration over the public Internet while utilizing 
existing master data sources: the simpler, the better. 
Figure 5 shows a sample NexPriseTM J-2X screen 
which uploaded the SEWG agenda for the May 15, 
2008 meeting. 

ARCHITECTURE DESIGN DESCRIPTION 

PWR utilized a simple spreadsheet entitled the 
Architectural Design Description (Table 2) to 
maintain control over rapidly changing architectural 
features of the J-2X in the pre-CDR phase of the 
program. The SIMPLE use of a spreadsheet to track 
architectural design changes provided design control 
during a period of rapidly changing design 
characteristics. Changes were monitored at the 
weekly SEWG meeting with NASA while trade 
studies were conducted to select the most desirable 
options. After the CDR a more traditional 


Configuration Control Board approach was implemented 
to control engine architecture. 

SAFETY ANALYSIS 

Crew and vehicle safety are major design considerations 
for the J-2X Program. The analysis required to evaluate 
the safety/reliability of the Ares vehicle systems is a 
highly developed process supported by large staffs both at 
NASA and PWR. The interconnected nature of familiar 
techniques such as Failure Modes and Effects Analysis 
(FMEA), Critical Items List (CIL), and Hazards Analysis 
demand a highly integrated approach in order to assure a 
meaningful analysis in such a complex system as a rocket 
engine. PWR has created a tool which uses computer 
technology to integrate the various techniques mentioned 
above. 

The Integrated Operability Toolbox (IOT) establishes a 
unified platform to associate and share operability 
analyses and data for product definitions and system 
implementation. Related information is readily available 
for Integrated Product Teams (IPTs) to support real-time 
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Fig. 5: Sample J-2X NexPriseTM Screen 

Table 2: Architectural Description Document - Outline Form 


Rev 

Document 

Revision 

Date 

Tab 

Action Description 

Old 

Value 

New 

Value 

Date 

Rationale A ? reed 

to in 

SEWG 

Significant 
Impact to 
Cost or 
Schedule? 

Conflicts 

~' th Notes 

Sys. 

Spec? 

2.5.2 

12/13/2006 

GG 

Changed 



12/7/2006 





GG 

Changed 



12/7/2006 





Subsystem 

View 

Added 



12/7/2006 





Hot Gas 
System 

Added 



12/8/2006 



2.5.3 

1/11/2007 

Subsvstem 

View 

Added 



12/20/2006 





Svs Int 

Added 



12/20/2006 





Electric 

Control 

Added 



1/3/2007 





Propellant 

Valves 

Changed 



1/3/2007 





Propellant 

Valves 

Changed 



1/3/2007 





Svs Int 

Changed 



1/3/2007 





Veh Inf 

Changed 



1/3/2007 
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decisions during design, assembly, development and 
sustained test and flight operations. The IOT data can 
also be referenced while developing new products. 

This tool integrates the operability infrastructure of 
several groups: Safety, Reliability, Maintainability 
and Testing (SRMT), Product Support, Design 
Engineering and Configuration Management. Linking 
the information obtained and stored by each 
functional group improves the design of the product 
life cycle, reduces cost and increases the system’s 
operational availability. 

The IOT is designed to link related operability 
analyses and data, namely information pertaining to 
Model Based Design, Design for Operability, 
Requirements Management, Risk Management, 
Operability Database, the Control & Health 
Management System (HMS), and the future 
Test/Flight Log Database. By centralizing and 
standardizing the access location for this related 
information, retrieval of the information required to 
make time-critical decisions is facilitated throughout 
the life of the product. Within the IOT, there are four 
main modules, the Failure Modes and Effects 
Analysis (FMEA), the Hazard Analysis, the 
Instrumentation Module, and the Supportability 
Tools module. Each module is tailored to the 
potential needs of disparate programs. The navigation 
between and within modules is accomplished through 
a main menu tool bar containing the four main 
modules. 

With the goal of process consistency in mind, the 
IOT is designed to consolidate the access point for 
diverse operability data. The IOT utilizes the 
integrated FMEA/HAR (Hazards Analysis Report) 
database as a basis to support the product life cycle. 
Product and process integration is achieved through 
direct links to the Product Support Toolbox, HMS 
architecture and a unified Reliability Maintainability 
and Testability (RMT) and Systems Safety (SS) data 
base. Design definition efforts are directly supported 
for current and future programs because knowledge 
capture continues for the entire product life cycle. 
Figure 6 is an example of the FMEA Version List 
screen from the IOT. 

RISK MANAGEMENT (PARAPHRASED FROM 
THE J-2X RISK MANAGEMENT PLAN) 

The objective of risk management is to apply a 
systematic process for identifying, assessing, 
handling, mitigating, and tracking risks that arise 
during a development program. As used here, the 
term ‘risk’ is defined as an undesirable situation or 
circumstance that has a realistic likelihood of 


occurring and that results in an unfavorable consequence 
if it does occur. Risks are characterized as being 
technical, schedule, or cost related, depending on the 
consequence of the risk if it occurs. Any risk not 
classified as either a cost or schedule risk is considered to 
be a technical risk. Safety risks are considered technical 
risks. Risk management occurs continuously throughout 
the program life cycle and consists of a six-step process: 
(1) Identify, (2) Analyze, (3) Plan, (4) Track, (5) Control, 
and (6) Communicate and Document. Risk management 
is performed at all levels of the program hierarchy. 
Integrated Product Teams (IPT) or other teams are best 
able to identify potential risk items at the lowest level 
within the system where handling those risks can 
frequently be accomplished with the least impact to the 
total system. 

A 5-by-5 risk assessment matrix provides a graphical 
representation of risk status. Risks are mapped on the 
matrix according to a likelihood and consequence 
assessment. Likelihood is measured on the vertical axis, 
and consequence is measured on the horizontal axis. Both 
axes consist of five levels of assessment for a total of 25 
likelihood-consequence combinations on the matrix. 
Green, yellow, and red colored regions on the matrix 
indicate areas of low, medium, and high risk, respectively. 
Figure 7 shows a typical 5-by-5 risk assessment matrix. 

Assessment Criteria 

Likelihood and consequence assessment criteria have 
been defined for evaluating risks. Each set of criteria has 
five levels of increasing likelihood and consequence 
severity. The likelihood assessment criteria consist of 
multiple sets of measures based on defined categories of 
risk consisting of general, design, integration, 
management, process, production, requirements, safety, 
software, supplier, supportability, technology, and others 
as appropriate. Similarly, the consequence assessment 
criteria consist of a set of measures for each risk 
consequence: technical, schedule, and cost. Technical 
includes anything that is not cost or schedule related such 
as design, management, production, safety, and others as 
appropriate. All red and yellow risks require a risk 
response such as avoid, transfer, assume, or mitigate. Risk 
response for green risks is optional and dependent on the 
nature of the risk. 
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Risk Assessment Code (RAC) Matrix 

NASA’s 5x5 RAC Reporting Matrix >* 
method uses qualitative measures of ■= 5 
risk likelihood with similar measures -Q 
of risk consequences to yield a RAC .q 4 

that is the basis for initial £ 

prioritization of risks. CL 

~o 

Low level risks (Green) & mid level 0 
risks (Yellow) are reported/monitored 2 
at team or group level of the = 

program/project. Q j 

□ 

Primary Risk Area (Red) impact the 
program/project at a high level and 
should be monitored at senior 
management level. 

Fig. 7: Risk Assessment Matrix 

Risk Management Database Software Tool — Risk 
Control 

To facilitate the implementation of the risk 
management process, the J-2X program uses a web- 
based program risk management database software 
tool known as RisControl. The tool facilitates the 
identification, assessment, planning, controlling, 
communicating, documenting, and reporting of risks. 
Tailored for the J-2X team structure and the 
assessment criteria, RisControl may be accessed by 
all program personnel. A regularly published risk 
status report features a 5-by-5 matrix showing the 
actual and scheduled risk reduction in likelihood and 
consequence assessment levels as a result of 
completing some risk events. Figure 8 is a sample 
5x5 matrix. Other reports feature time-phased 
mitigation plans. 

CONFIGURATION MANAGEMENT 
(PARAPHRASED FROM THE J-2X 
CONFIGURATION MANAGEMENT PLAN) 

The objective of Configuration Management (CM) is 
to implement an organized, efficient, and accurate 
process for managing the configuration of hardware, 
software, and related data products. CM encompasses 
the total product life cycle and results in accurate, 
consistently managed, and verified as-designed, as- 
planned, as-built and as-maintained product 
configurations, and program data. This includes: 
configuration identification and defining 
Configuration Items (Cl); the control of changes to 
established baselines; configuration verification; 
maintaining of configuration status accounting 
records and reports; and participation in CM related 
reviews and audits. 

The tool PWR uses for configuration management on 
J-2X is named the Enterprise Process and Data 
Management system, EPDM. It is a computer data 
based tool which gives multiple users simultaneous 
access to documents and drawings to enable review, 


release, version control, and electronic archiving 
functions. EPDM is used to manage product and process 
related information throughout the entire product life 
cycle. The system allows information sharing regardless 
of user location, data location, or hardware platform. End 
users can access the system through a secure, password 
protected web interface to review and approve or search 
for documents and view them on-line or print copies of 
them. 

EPDM is a SIMPLE and powerful program resource that 
enables cost effective communication and data 
accessibility. It provides a system that facilitates the 
creation, collaboration, review, approval, distribution and 
vaulting of J-2X documentation. By using a web-based 
system, any authorized user within the enterprise can 
access the documentation from their work site, greatly 
improving the accessibility of the data. It gives the end 
users access to formally released data, as well as work in 
process. Tailoring the system to J-2X processes, such as 
the Build-To Package process, has improved 
collaboration, both in-house and with suppliers, and 
reduced cycle time in comparison to manual paper 
systems. A Build-To Package (BTP) is an integrated, 
electronic package that contains the complete product 
definition, and the traditional “what to build” and “how to 
build it” information for a particular part or assembly. 
What distinguishes the BTP process from traditional 
methods of product definition is not the documentation 
itself but the manner in which it is created and managed. 
It is created with parallel processes as a shared 
responsibility of a multifunctional Integrated Product 
Team (IPT). A pre-release vault, called the Team Vault, 
was created to facilitate collaboration within the team 
prior to formal release. In addition to the Drawing and 


Risk 9: J-2X Engine Vfeight 



Fig. 8: Individual Risk Status Report Chart 



8 


other model derivative files, Supplier, Quality and 
Manufacturing requirements have been added to the 
composition of the BTP, along with links to 
applicable documents, including Specifications, 
resulting in a single source for data required to 
manufacture or purchase the part or assembly. The 
BTP is released and configuration managed as a 
single, integrated entity. An automated interface 
flows the Bill of Material from EPDM to the 
manufacturing control system further improving 
communication between design engineers and 
manufacturing and eliminating redundant data entry. 
Implementation of the EPDM BTP process has 
resulted in significant reduction in cycle time for the 
entire drawing release, requisition release, and 
purchase order placement life cycle. Figure 9 is a 
sample screen from just one of EPDM’s functional 
areas. 

THINGS WE LEFT OUT 

It would have taken a lot more space in this paper to 
adequately describe the entire range of SE tools and 
technique utilized on the J-2X program. Some of 


those we skipped are mentioned in this paragraph in an 
attempt at abbreviated completeness. 

At its best SE is integrated into every part of the J-2X 
program in such a way that its influence brings simple 
solutions and processes to complex development issues. 
The principle of employing uniform processes across a 
complex and dynamically changing program is an 
example of clear communication processes. A good 
example of this is the SE practice of establishing a set of 
comprehensive “technical performance measurements” at 
the beginning of the program that define key 
characteristics of the engine system. Propulsion system 
goals such as predicted Specific Impulse (Isp), engine 
weight, reliability targets, and production cost are 
carefully monitored and tracked on a monthly basis. 

Another SE tool is the use of analytical modeling of 
engine system and component performance. Using 
advanced modeling techniques such as computational 
fluid dynamics (CFD) to develop component designs 
reduces risk of achieving performance goals at 
component, subsystem, and engine system levels. The 
J-2X program also makes use of computerized material 



Fig. 9: EPDM Document Search Function Screen 
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property databases to assist in component design. 
Available information is supplemented with a 
growing body of material knowledge that is being 
generated as part of the program. Risks associated 
with critical flaw size and probability of detection are 
included and become part of the technical design 
process. 

The simple process of using more experienced 
employees to mentor younger or less experienced 
employees is a vital part of the SE process. Investing 
the time and effort to help others not only brings 
efficiency to the J-2X development process but is an 
effective means of sharing and spreading SE 
principles throughout the organization. 

SUMMARY 

The J-2X engine development program continues to 
support the Ares Program goals of returning 
astronauts to the moon and moving out to explore the 
solar system. The implementation of SE principles 
with good communication practices is integral to the 
success of this effort and central to the strategy of 
unifying all elements of the program. The simplest 
communication tool of regular conversations among 
NASA, contractors, and sub-contractors is fully 
utilized to ensure not just the transfer and flow down 


of requirements but the proper understanding of those 
requirements and the potential subtle nuances which may 
turn into problems. Regular teleconferences, technical 
interchange meetings, working groups using electronic 
communication tools and face to face contact among real 
people is the simplest and yet most effective tool for 
ensuring the success of the SE effort on J-2X. Electronic 
data handling tools (NexPriseTM, EPDM, IOT, etc.) 
ensure consistency of information and controlled change 
of requirements. The simple act of recording and 
monitoring the architectural change decisions in the 
Architecture Description Document maintains vigilance 
over multiple changes and encourages the engineering 
community to continually evaluate the impact of the range 
of changes from a broader systems perspective. The 
complex J-2X Hazards Analysis effort is simplified by the 
use of the IOT which ensures the proper interrelationship 
among the design details, FMEA information, and the 
CIL. But the proof of SE is in successful program 
accomplishment. SE is the methodology being used to 
meet the challenge of completing J-2X engine 
certification 2 years ahead of any engine program ever 
developed at PWR. This approach has delivered 
according to expectations thus far. All major design 
reviews have been successfully conducted satisfying 
overall project and program objectives using SE as the 
basis for accomplishment. It would seem that William of 
Ockham was on to something. 
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Bill Kelly (PWR - Canoga Park, CA) 

Bil Greene (NASA - MSFC) 

Paul Greasley (PWR - West Palm Beach, FL) 
Pete Ackerman (PWR - Canoga Park, CA) 



Systems 
Engineering 
for J-2X 
Development: 
The Simpler, 
the Better 






•Based on J-2 historical success 
•SE principles simplify development 
• Better SE tools and techniques 


S-IVB 
(1 J-2) 


S-ll 
(5 J-2) 


Ares-I Crew Launch Vehicle (CLV) and 
Ares-V Cargo Launch Vehicle (CaLV) 
• Safer 

•More reliable 

•Operationally more efficient 


Ares-I CLV Ares-V CaLV Saturn V 
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Technologies Company 


A United 


J-2X SE: The Simpler, the Better 
A Simple Communication Plan 


•Technical requirements flowdown 

•Structured program requirements 

• Tiered flowdown provides 
traceability between levels 

• J-2X Element Requirements 
Documents provides basic 
engine design parameters 

• J-2X Engine System Specification 
decomposes ERD into engine 
level details 
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J-2X SE: The Simpler, the Better 


United Technologies Company 


SE Team 


Element Requirements Provided 


to PWR 


•Simple relationship between PWR and NASASE efforts 
• PWR SE Organization Parallels NASA 
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Technologies Company 


J-2X SE: The Simpler, the Better w 

Working Meetings Mean Talking To Each Other 


•Simple and effective way to achieve high quality communication 
•15 regular meetings between PWR and NASA 
•Opportunity for technical experts to discuss mutual interests 


Meeting 

Title 

Lead 

Team 

Attendees 

Objectives/Purpose/Charter 

Decision Making 
Authority 

Frequency 

SEWG 

Office of 

Chief 

Engr 

PWR SEIT & IPT 
Leads & PM/DPM; 
NASA Chief Engr, 
SEIT Lead, & Prog 
Office; Architects; 
Integrators 

Operated as an ERB. 
Coordination, integration, and 
review of significant technical 
and design efforts 

A decision 
making body for 
technical items & 
issues 

Weekly 

EDWG 

SEIT 

Lead dev person or 
designated dev rep 
from each IPT 

EDWG is held in order to 
discuss system functional 
integration, trade studies, and 
architecture development 
issues 

A working 
meeting to 
develop 

recommendations 
for SEWG. 

Weekly 

EIWG 

Eng Integ 

Lead designer or 
designated design rep 
from each design IPT 

Coordination forum for physical 
layout and integration of the 
engine system. Also to work 
physical interface trades with 
vehicle. 

A working 
meeting to 
develop 

recommendations 
for SEWG. 

Weekly 
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J-2X SE: The Simpler, the Better w 

ADD Provides Control With Demanding Schedule 


Pratt & Whitney 

A United Technologies Cbmpany 


•Engine Architecture Design Description (ADD) 

•Simple spreadsheet to track configuration and changes 
•Changes monitored during weekly PWR / NASA meetings 
•Changes made by Configuration Control Board after CDR 


Rev 

Document 

Revision 

Date 

Tab 

Action 

Description 

Old 

Value 

New 

Value 

Rationale 

Date 
Agreed 
to in 
SEWG 

Significant 
Impact to 
Cost or 
Schedule? 

Conflicts 
with Sys. 
Spec? 

Notes 

2.5.2 

12/13/2006 

GG 

Changed 





12/7/2006 






GG 

Changed 





12/7/2006 






Subsystem 

View 

Added 





12/7/2006 




2.5.3 

1/11/2007 

Subsystem 

View 

Added 





12/20/2006 






Svs Int 

Added 





12/20/2006 






Electric 

Control 

Added 





01/03/2007 
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The Simpler, the Better 


A United Technologies Company 


NEXPRISE 


Secure Communication 


Provides 


• Electronic communication via secure Internet tool 
•Simple and safe means to share vital information 

• Electronic communication tools enhance clarity and speed 


KLOSE L£ 3 El "v 1 Q S 

fl-i nr rrrr rm I nw niEil rar hirm <1 nr Irgiffi I tpi ■w- if — Ewimri I jar I tar rttmm Ttnn I mjfiMi f un I nr* rn^ 1 un Ttwit 
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Integrated Operability Toolbox (IOT) 

• Unified platform to associate and share 
operability analyses and data 

• Integrates efforts of various groups - 
Safety, Reliability, Maintainability and 
Testing, Product Support, Design 
Engineering, Configuration Management 




Failure modes can be linked to Bill of 
Material assembly 

• Simple coordination of activities 

• Reliable tool for design work 
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A United Technologies Company 


J-2X SE: The Simpler, the BetterTO^i 
RisControl Simplifies Risk Management 


Risk 9: J-2X Engine Vfeight 


Risk Assessment Matrix 
•Graphical representation of risk status 
• Electronic database used to monitor 
risk items 

•Simple communication tool between 
PWR and NASA 


Risk Assessment Code (RAC) Matrix 


NASA’s 5x5 RAC Reporting Matrix 
method uses qualitative measures of 
risk likelihood with similar measures 
of risk consequences to yield a RAC 
that is the basis for initial 
prioritization of risks. 

Low level risks (Green) & mid level 
risks (Yellow) are reported/monitored 
at team or group level of the 
program/project. 



Primary Risk Area (Red) impact the 
program/project at a high level and 
should be monitored at senior 
management level. 




Actual 


Schedule 

- - H-- 


Individual Risk Status Report Chart 
•Likelihood and consequence 
•Colors indicate severity 
• Effective tool for tracking risk 
mitigation plans 
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Technologies Company 


A United 


J-2X SE: The Simpler, the Betterj |a|| 

EPDM Simplifies Configuration Management 


Enterprise Process Data Management (EPDM) 

• Electronic tool that gives multiple users simultaneous access to 
documents and drawings 

•Used to enable review, release, control, and electronic archiving 
•Simple and powerful tool that enables cost effective 
communication and data accessibility 
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•Creative use of advanced technology 
tools 

•Technical performance measurements 
tracking 

•Analytical modeling of engine and 
component performance 

•Training and mentoring of new 
employees 
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•“All Things Being Equal, The Simplest Solution Is The Best” - 
William of Ockham 

•“Talking To Each Other” 

•Simple but effective communication in meetings and telecons 
•Simple monitoring tools (ADD, etc.) keep focus on the details 
•Safety tools integrate technical efforts of many engineers 
•Success via simple and better SE practices 
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